home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0346.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  2.9 KB  |  74 lines
  1. I've reconsidered my position on the "framing tags" in HTML after
  2. a more careful consideration of the SGML standard, and after
  3. receiving the O'Reilly/HaL DocBook materials and the MidasWWW
  4. browser.
  5.  
  6. To refresh your memory...
  7.  
  8. >     Currently HTML documents are transmitted without the normal SGML framing
  9. >     tags, but if these are included parsers will ignore them.
  10. >
  11. >I don't know what "the normal SGML framing tags" are. An SGML document
  12. >has three parts: the SGML declaration, the prologue, and the instance.
  13. >It is common in SGML applications to use an implied SGML declaration
  14. >and include the prologue by reference (kinda like an #include
  15. >directive in C.) but without these "framing tags," it's just not an
  16. >SGML document.
  17.  
  18. The SGML standard is big on the distinction between Entities and
  19. everything else; that is, the physical breakup of an SGML document
  20. into storage units such as files, directories, MIME body parts,
  21. collectively "entities" is pretty much arbitrary (you can't break
  22. <TITLE> between <TI and TLE>,, but other than that,
  23. it's pretty much fair game.)
  24.  
  25. So it appears that it's not necessary or even wise to model the HTML
  26. data format as an SGML document entity, but rather an SGML text
  27. entity.  That is, the way to validate/parse an HTML document is not to
  28. sick the parser on the text/html body part itself, but on a document
  29. consisting of two entities: the HTML DTD entity, and the text/html
  30. body part.
  31.  
  32. If we were talking about a text/c-program content type, what I
  33. was suggesting would be like putting the line:
  34.  
  35. #include <stdlib.h>
  36.  
  37. at the top of every text/c-program body part. What I'm suggesting
  38. now is like assuming every text/c-program gets stdlib.h prepended
  39. before compiling.
  40.  
  41. This makes an assumption that text/html data has this HTML DTD
  42. entity in front of it all the time, but that assumption has always
  43. been there.
  44.  
  45. Besides, forcing text/html parser to grok SGML document entities
  46. creates some sticky issues -- we'd have to limit the prologue
  47. to the simple <!DOCTYPE HTML SYSTEM>, and that's not really legal.
  48. You're supposed to be able to do things like:
  49.  
  50. <!DOCTYPE HTML SYSTEM [
  51. <!ENTITY smiley ":-)"> <!-- add my own "macro" -->
  52. ]>
  53. <HTML><TITLE>The history of the smiley: &smiley;</TITLE>
  54. ...
  55.  
  56. If we adopt this change of perspective, we should make it clear
  57. in the HTML specification that for the purposes of SGML, a text/html
  58. body part is not an SGML document entity, but an SGML text
  59. entity. The html.dtd entity and the text/html body part text entity
  60. comprise an SGML document. I need to update html.dtd, fix-html.pl,
  61. and the www_and_frame materials to reflect this change of
  62. perspective.
  63.  
  64. By the way: this change makes it more staightforward to use an
  65. SGML declaration other than the default, e.g. to increase NAMELEN
  66. to allow tags larger than 8 characters. Should we do that while
  67. we're at it?
  68.  
  69. Dan
  70.  
  71. p.s. Check out the MidasWWW browser. It's long overdue in the WWW
  72. project, but it's worth the wait!
  73.  
  74.